Dann können wir starten. Es freut mich, dass heute so viele Leute doch noch gekommen sind.

Ich habe schon gedacht, dass wir heute einen völlig leeren Hörsaal haben. Aber danke fürs Kommen.

Die letzte Vorlesung in dem Jahr, so kurz vor den Weihnachtsferien. Vielen Dank fürs Erscheinen.

Heute werden wir uns Themen zur Implementierung anschauen.

Wir können vielleicht noch mal kurz nachdenken, was wir alles gemacht haben in der Vorlesung Software Engineering.

Wir haben von vorne angefangen und uns überlegt, was ist denn Software? Warum brauchen wir spezielle Abläufe, um Software herzustellen?

Dann haben wir uns angeguckt, wie man das gut tun kann.

Wir haben uns auch überlegt, wie man überhaupt damit anfängt, wie man sich mit Anforderungen ermittelt.

Dass das ein entscheidender Schritt ist, dass sich Anforderungen und Software allgemein auch ständig ändern können.

Dann haben wir uns angeguckt, dass man über verschiedene Paradigmen oder verschiedene Ansätze erfolgreich Software entwickeln kann.

Wir haben uns sehr viel über agile Implementierungen geredet und sind Stück für Stück immer mehr in die Implementierung gekommen.

Wir haben uns in den letzten Vorlesungen die Architekturen überlegt, wie das aussehen kann.

Wir haben uns dann Entwurfsmuster angeschaut, welche Patentrezepte, best practices gibt es denn, solche Entwurfsmuster zu generieren.

Wie kann dann der entsprechende Klassenentwurf und die entsprechende Implementierung erfolgen?

Heute wollen wir uns wirklich angucken, wie es mit der Implementierung läuft.

Wir haben hier auch ein paar Do's und Don'ts, wie man implementieren sollte.

Warum gibt es Coding-Richtlinien und warum sollte man sich daran halten?

Dann ist das Ganze natürlich auch wieder ein bisschen abstrakt, weil die konkreten Coding-Richtlinien sich natürlich von Fall zu Fall unterscheiden.

Die müssen auch so ausgesucht werden, was für die jeweiligen Teams funktioniert.

Natürlich wollen die auch konsistente Software bauen, dass man die Sachen wiedererkennt, sich dort einarbeiten kann.

Das sind so die Themen, die wir uns heute ein bisschen angucken wollen.

Häufig verwenden wir Standards, um Implementierungen herzustellen.

Das Problem tritt eben auf, wenn jeder in seinem eigenen Coding-Stil, das ist vielleicht alles dieselbe Programmiersprache,

muss noch nicht mal dieselbe Programmiersprache sein.

Es kann natürlich auch sein, dass quasi dann Mischungen verwendet werden.

Aber wenn jeder einfach drauf losarbeitet in seinem Stil, dann ist das für andere halt schwer nachzuvollziehen.

Und es gibt auch kein konsistentes Build-up.

Man kommt eben dann schlecht in den Code von jemand anderes rein.

Und diese Standards helfen uns quasi, die Codequalität zu verbessern, das zu vereinheitlichen.

Es kann dazu führen, dass wir schneller programmieren können, insbesondere im Team, weil man besser zusammenarbeiten kann,

weil alle nach denselben Richtlinien implementieren.

Also eventuell, wenn ich ein guter Programmierer bin, dann komme ich vielleicht alleine schneller klar.

Aber sobald ich mit jemandem anders zusammenarbeiten muss, dann ergeben sich dort entsprechende Reibungen.

Und deswegen hilft es quasi auch dem Team Spirit, das Teamwork besser zusammenzuführen und hilft dann insgesamt den Entwicklern.

Und natürlich sind solche Coding-Richtlinien, die sollte man am Anfang festlegen, aber ab und zu macht es auch einfach Sinn,

sich hinzusetzen und sich zu überlegen, passen die Richtlinien noch zu uns?

Ist das so, wie wir implementieren wollen oder haben wir uns Richtlinien gemacht, die uns selber behindern?

Und dann müssen wir natürlich die Richtlinien anpassen.

Also das ist auch wichtig, dass wenn wir quasi solche Implementierungs-Guidelines haben, also Standards,

dass wir uns auch überlegen, ob das noch zu uns passt.

Gut, und typischerweise sind diese Standards dann abhängig davon, wie es in der Organisation an sich aussieht,

wie es in dem Team zurechtkommt.

Hängt natürlich auch davon ab, welche Programmiersprache wird eingesetzt.

Es kann sein, dass gewisse Vorgaben auch schon durch die Programmiersprache gemacht werden.

Und dann natürlich auch die Erfahrung der einzelnen Entwicklern.

Und natürlich kann es auch sein, dass es spezifische Dinge in dem Projekt gibt,

die eben dafür sorgen, dass man entsprechende Guidelines anpassen muss.

Also insgesamt sollte so ein Standard dann auf Konzepten basieren, Regeln funktionieren

und quasi Implementierstandards basieren, die funktioniert haben.

Ich übernehme quasi Regeln, von denen ich weiß, dass sie schon gut funktioniert haben.